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ABSTRACT 


We  describe  some  of  the  experimental  knowledge-based  software  develop¬ 
ment  tools  undei  development  at  Kestrel  Institute.  In  particular,  systems 
1^  for  automatically  performing  algorithm  design,  deductive  inference,  finite 

differencing,  and  data  structure  selection  are  discussed.  A  detailed  case 
study  is  presented  that  shows  how  these  systems  could  cooperate  in  sup¬ 
porting  the  transformation  of  a  formal  specification  into  efficient  code. 
The  example  treated  is  a  schedule  optimization  problem. 
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1  Introduction 

I 

The  purpose  of  a  programming  environment  is  to  enhance  progranuning  produc¬ 
tivity.  A  comprehensive  environment  provides  integrated  tools  that  assist  with  all 
aspects  of  the  software  development  process:  specification  acquisition  and  develop- 
I  ment,  implementation,  testing,  integration,  maintenance,  project  management,  and 

communication  among  the  designers  and  users  of  the  system.  The  Knowledge-Based 
Software  Assistant  (KBSA)  approach  [13]  advocated  the  building  of  a  comprehensive, 
integrated,  software  development  environment  that  contuned  formalized  knowledge 
about  each  aspect  of  the  programming  process.  In  particular,  it  advocated  the  fol- 
I  lowing  design  principles. 
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1 .  The  software  development  process  should  revolve  around  the  development  of  for¬ 
mal,  very-high- level  specifications  from  which  efficient  code  is  synthesized.  The 
specifications  should  be  executable  in  order  to  allow  testing.  The  maintenance 
process  should  concentrate  on  evolving  the  specifications  and  resynthesizing 
efficient  implementations,  rather  than  evolving  the  code. 

2.  All  the  objects  relevant  to  the  programming  process,  e.g.  specifications  at  all 
levels  of  refinement,  derivations,  test  cases  and  results,  project  plans,  bug  re¬ 
ports,  should  be  captured  in  a  knowledge-base. 

3.  There  should  be  knowledge-based  support  for  all  facets  of  the  programming 
process,  including  automated  implementation.  Here,  the  term  automated  means 
that  the  process  is  carried  out  by  the  machine,  either  automatically  or  under 
human  guidance. 


Focusing  the  software  process  on  the  development  of  very-high-level  specifications 
factors  the  implementation  of  the  problem  from  its  specification.  This  should  amelio¬ 
rate  the  maintenance  problem,  because  It  is  easier  to  maintain  perspicuous,  modular 
specifications  that  lack  the  implementation  detail  of  source  code. 

Automatic  compilers  for  the  specification  language  allow  the  designer  to  rapidly  con¬ 
struct  executable  prototypes  of  a  specification.  Experience  gained  with  such  pro¬ 
totypes  assures  the  designer  that  the  specification  is  valid;  i.e.  that  it  specifies  the 
desired  behavior  in  the  context  in  which  the  system  is  embedded. 

Kestrel  research  has  focused  on  (1)  the  architecture  of  such  an  environment,  and  (2) 
development  of  formal  theories  that  can  be  used  to  support  aspects  of  the  software  de¬ 
velopment  process.  The  architecture  of  an  environment  embodying  the  KBSA  design 
principles  should  be  highly  integrated;  one  where  knowledge  is  explicit  and  manip- 
ulable  by  the  environment  itself.  The  architecture  of  a  self- described  programming 
environment  was  outlined  in  [27]  (cf.  [21]).  We  propose  that  a  KBSA  should  contain 
the  following  components. 


1.  A  knowledge  base  manager  iha.i  manages  representations  of  all  software  process 
objects,  e.g.  programs,  including  a  representation  of  their  abstract  syntax  an¬ 
notated  with  dataflow  and  other  assertions,  derivation  histories,  mathematical 
facts,  program  transformation  rules,  bug  reports,  project  schedules. 

2.  A  single  wide-spectrum,  very-high-level  language  used  to  (1)  express  programs 
and  specifications  at  all  levels  of  refinement;  (2)  query  and  modify  the  environ¬ 
ment’s  knowledge  base;  (3)  express  programming  knowledge,  such  as  program 
transformations,  efficiency  characteristics,  and  other  facts.  Such  a  language 
should  integrate  constructs  from  predicate  calculus,  set  theory,  and  standard 
imperative  programming  languages. 
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3.  A  formal  body  of  knowledge  about  the  software  development  process.  In  par¬ 
ticular,  we  propose  that  the  implementation  process  be  formalized  as  one  of 
program  refinement  by  the  application  of  a  body  of  program  transformation 
rules.  Implementation  knowledge  that  is  specific  to  an  application  domain  is 
necessary  also  (e.g.  [3,39]).  Other  software  development  aspects  that  could  be 
formalized  are  performance  estimation  (e.g.  [16]),  version  control  (e.g.  [28,26]), 
designer  communication  (e.g.  [17]),  task  scheduling  and  project  management 
(e.g.  (25.6)). 

The  CHI  system  [36]  developed  at  Kestrel  was  an  apprcodmation  to  this  architecture. 
It  contained  a  frame-oriented  knowledge  base  manager,  a  partly- compilable  language 
called  V  with  a  variety  of  constructs,  and  scjme  theories  that  were  codified  in  the 
language.  In  particular,  encoded  in  CHI  were  theories  fan  generating  data  structure 
implementations  [9],  which  wail  be  mentioned  agzun  later;  synthesizing  database  up¬ 
dates  [14];  and  automating  the  communication  atnoag  designers  [17].  The  V  language 
contained  a  transformation  <xmsi.Tact  that  vrss.  arsed  to  express  program  transforma¬ 
tions. 

The  Refine*  system  [1]  is.  a  conrateatiaSly  awadlable  environment,  beised  on  the  ar¬ 
chitectural  ideas  in  the  CM  systesaa.  It  oonlains  an  entity-attribute  style  database 
manager,  accessed  via  the  RXFITVE  language.  We  have  dleveloped  research  proto¬ 
types  using  the  REFINE  enriionment  that  demonstrate  algorithm  design  [35],  logic 
compilation  [38],  program  optimization  [5].,  ptarformance  estimation  [10],  and  project 
management,  task  scheduBjig,  bmg  trariing,  and  versicat  conlirol  [15]. 

This  paper  concentrates  xm  specifitataon  msplementationi)  tnowledge.  We  show  how 
to  derive  an  efficient  implenaesaiSation  of  a  vcry-high-ievvll  specification  of  a  scheduling 
problem.  We  show  the  use<of  the  -specificatiom  language,  and  how  various  kinds  of  im¬ 
plementation  knowledge  come  into  pilay  in  the  derivatkaii..  Before  the  actual  derivation 
is  presented,  two  pieces  of  implementation  knowledge  wilS  be  described:  the  algorithm 
design  tactic  for  subspace  generators  I33j  as  applied  to  optimization  problems,  and 
the  finite-differencing  program  optimizatioffi.  technique  Implementation  knowledge 
for  data  structure  generaitaon  and  performance  estimat-acau  will  be  mentioned  briefly 

Underlying  our  approach  is  the  goal  of  an  autramatic  programming  system  that  needs 
little  human  guidance.  This  has  been  exemplified  by  our  work  in  algorithm  de¬ 
sign.  We  have  tried  to  explicate  the  structure  of  various  cl2isses  of  algorithms  such 
as  branch-and-bound  and  divide-and-conquer.  Systems  we  have  built  can  construct 
automatically  (for  the  most  part)  these  sorts  of  algorithms  for  a  given  problem  spec¬ 
ification.  One  feature  of  our  approach  is  that  our  algorithm  design  tactics  motivate 
the  inferences  and  decision-making  that  have  to  be  made  to  synthesize  an  algorithm. 
In  contrast,  work  such  as  [8,23,37]  is  more  concerned  with  correct,  human -developed 
proofs  and  program  derivations.  In  our  approach,  certain  kinds  of  intermediate  re¬ 
sults  (lemmas,  equivalent  expressions,  lower  bounds,  etc.)  are  sought  because  general 
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knowledge  about  the  type  of  algorithm  being  constructed  allows  them  to  be  formally 
characterized.  An  inference  system  can  then  take  the  formal  characterization  and 
produce  the  desired  result.  Inference  is  only  performed  in  highly  constrained  con¬ 
texts  and  towards  specific  goals.  This  allows  the  tactics  to  work  automatically.  See 
[7,H,24]  for  surveys  of  approaches  to  specification  implementation. 

The  specification/programming  language  used  in  this  paper  is  loosely  based  on  the 
Refine™  language.  Specifications  in  this  paper  should  be  comprehensible  because  of 
the  similarity  of  the  language  to  standard  programming  and  mathematical  notation. 
A  few  notes  are  in  order.  The  language  contains  the  standard  datatypes  integer, 
natno  (natural  number)  and  the  following  datatype  constructors. 

seq(r)  sequences  of  elements  of  type  r 

set(r)  sets  of  elements  of  type  r 

bag(T)  multisets  of  elements  of  type  r 

binrel(Ti,T2)  binary  relations  on  Ti  x  T2 
Ti  — ♦  rj  mappings  from  Ti  to  T2 

Examples  of  the  sequence  operations  concat,  append,  prepend,  and  reduce  follow: 
concat{[l,2],  (3,4])  =  [1,2, 3, 4);  appcnd([l,2], 3)  =  [1,2,3];  prepend{[l,2],0)  =  [0, 1,2]; 
reduce(-l-,  [1,2,3])  =  ! +2+3=6.  The  expression  elements- of  {S)  returns  the  elements 
in  the  sequence  5  as  a  bag.  The  standard  operations  on  sets  are  provided,  e.g.  £, 
U,  {f{^)  !  •P(a:)}-  Mappings  may  be  defined  using  A-expressions.  The  function 
minintum{/,5)  returns  some  element  of  the  set  S  that  minimizes  the  function  /. 
The  form  assert  P  in  E  announces  that  the  assertion  P  holds  upon  entry  to  the 
expression  E.  Such  an  assertion  suggests  that  E  may  be  simplified  because  it  occurs 
in  a  context  where  P  holds. 

This  paper  suggests,  but  cannot  prove,  the  contention  that  such  an  environment  will 
improve  productivity.  Our  experience  with  the  REFINE  language  and  environment, 
and  the  experience  of  others  with  other  very-high-level  language- based  environments, 
such  as  SETL  [20],  lend  credence  to  such  a  contention. 


2  Knowledge  about  Specification  Implementation 


We  now  introduce  some  techniques  for  designing  algorithms  and  optimizing  programs. 
These  techniques  are  formal  and  automatable  and  are  embodied  in  several  imple¬ 
mented  systems  at  Kestrel.  The  techniques  require  deductive  inference  only  in  a 
carefully  controlled  way  called  directed  inference,  which  is  also  described. 


2.1  Search  and  Optimization  Algorithm  Design  Strategies 


Many  problems  may  be  posed  as  search  problems;  given  some  input  parameters  x 
over  an  input  domain  D  (i.e.  x  £  D  holds),  find  an  object  2  that  satisfies  0{x,  i). 
where  O  is  a  given  predicate  called  the  goal  constraint.  Each  such  z  satisfying  the 
goal  constraint  is  called  a  feasible  solution  to  the  search  problem.  The  generate-and- 
test  algorithm  strategy  is  the  most  general  kind  of  algorithm  for  solving  such  a  search 
problem.  It  assumes  that  the  sought-after  object  lies  in  a  domain  R,  called  the  solution 
space,  that  can  be  enumerated.  The  so-called  “British-Museum”  generate-and-lest 
algorithm  simply  enumerates  each  item  z  in  R,  returning  a  z  for  which  0{x,  z). 

The  goal  of  an  optimization  problem  is  to  find  a  solution  that  is  feasible,  but,  moreover. 
optimal,  in  some  sense,  over  all  the  feasible  solutions.  The  generate-and-test  algorithm 
scheme  can  be  applied  to  solve  an  optimization  problem  also:  one  enumerates  all  the 
feasible  solutions  searching  for  an  optimal  one. 

A  refinement  of  the  British  Museum  algorithm  strategy,  called  subspace  generatoi 
searches  more  efficiently  by  exploiting  characteristics  of  the  goal  constraint  O  and  the 
solution  space  R.  To  motivate  this  strategy,  consider  the  problem  of  searching  for 
a  particular  Early  Greek  statue  in  the  British  museum  (given  that  we  have  lost  our 
museum  guide).  The  search  can  be  made  more  efficient  by  exploiting  the  structure 
of  the  museum,  that  iS,  as  a  set  of  galleries.  Information  about  a  gallery  may  help  to 
eliminate  each  object  in  the  gallery  as  a  possibility.  For  example,  every  object  in  a 
gallery  labeled  “Coins  and  Medals”  can  be  eliminated  a  priori. 

More  formally,  the  subspace  generator  algorithm  scheme  requires  that  each  of  the 
following  program  items  be  synthesized. 


1 .  a  function  Initial-Subspace[x)  that  returns  the  initial  solution  space  to  be  searched 

2.  a  function  Split{x,r)  that,  given  a  subspace  f,  returns  a  set  {ri,...,f„}  of 
smaller,  disjoint  subspaces; 

3.  an  efficient  necessary  condition  $(i,  f)  that  will  serve  to  filter  out  those  sub¬ 
spaces  f  that  cannot  contain  a  feasible  solution; 

4.  a  function  for  extracting  an  answer  from  a  subspace.  For  example,  if  we  have 
determined  that  the  statue  must  be  in  gallery  409,  then  if  we  know  that  gallery 
409  has  only  one  object  in  it,  we  can  easily  close  in  on  the  statue  in  the  gallery. 


Once  synthesized,  these  program  items  may  be  inserted  into  slots  in  an  algorithm 
template,  producing  a  program  that  provably  solves  the  original  problem. 

We  briefly  show  how  a  familiar  problem  can  be  solved  by  applying  the  subspace 
generator  strategy.  The  problem  is;  given  an  element  x  and  an  ordered  sequence  S, 


find  the  index  i  at  which  x  is  located  in  5,  i.e.  S{i)  =  x.  The  initial  solution  space  for 
this  problem  are  the  indices  in  the  interval  [1 . .  size  iS}]. 

Each  algorithm  design  strategies  requires  a  library  of  supplementary  methods.  The 
subspace  generator  scheme  requires  methods  for  splitting  a  subspace  of  some  particu¬ 
lar  datatype  into  subspaces.  Several  splitting  functions  are  available  for  the  data  type 
of  intervals.  One  way  of  subdividing  an  interval  into  subintervals  is  singleton- spUt: 
the  interval  f/. .  u]  (where  a  —  I  >  1)  is  divided  into  the  intervals  [/]  and  [(/  -f  1 ) . .  u]. 
Another  is  split-in-half:  the  interval  {I  ..u]  is  split  into  [/ . .  and  . .  u]. 

Because  the  given  sequence  S  is  ordered,  there  is  an  efficient  necessary  condition, 
described  in  the  next  section,  for  deciding  whether  a  given  subintervai  [T.u]  could 
possibly  contain  an  index  i  for  which  5(i)  =  x.  Once  the  splitting  process  divides 
the  solution  space  into  an  interval  of  length  1,  we  can  test  whether  the  sole  member 
of  the  interval  is  the  desired  index.  The  splitting  function,  necessary  condition,  etc. 
can  be  inserted  into  the  subspace  generator  algorithm  template  to  produce  a  search 
algorithm. 

One  critical  item  in  synthesizing  the  subspace  generator  is  the  synthesis  of  the  efficient 
necessary  condition  $  where 

Vx,  f  [x  e  £)  =>  (3  2  [2  €  r  A  0(i,  2)]  $(5,  f))].  (1) 

The  justification  for  this  condition  is  that  if  $  fails  on  some  subspace  descriptor  f,  i.e. 
-’$(x,  f)  holds,  then  by  the  contrapositive  of  (1)  there  are  no  feasible  solutions  in  f 
and  hence  the  entire  subspace  r  can  be  safely  eliminated  from  further  consideration. 

Branch-and-bound  algorithms  that  find  optimal  solutions,  not  just  feasible  ones,  can 
be  constructed  using  the  subspace  generator  scheme.  A  subspace  f  can  be  eliminated 
if  it  can  be  shown  that  every  solution  in  the  subspace  has  cost  worse  than  that 
achieved  by  a  solution  that,  has  already  been  found.  The  necessary  condition  is  thus 
of  the  form  lb(r)  <  ub,  where  ub  is  the  cost  of  the  best  solution  found  so  far,  and 
lb  is  a  function  that  can  ooflnpute,  given  a  subspace  f,  a  lower  bound  on  the  cost  of 
solutions  in  f. 

Necessary  conditions  and  lower  bound  functions  can  be  synthesized  by  applications 
of  directed  inference,  descrifoed  next. 


2.2  Directed  Inference 

Directed  inference  generafaes  the  standard  notions  of  theorem-proving  and  formula 
simplification.  Given  some  assumptions  A  over  variables  i,  and  a  source  formula  F, 
the  goal  is  to  find  a  formula  4)  that  (1)  satisfies  some  syntactic  constraints,  e.g.  its 
free  variables  y  are  a  subset  of  a  given  set;  (2)  optimizes  some  cost  function,  e.g.  in 
terms  of  syntactic  simplicity  and  semantic  strength*;  and  (3)  that  bears  a  specified 

predicate  p{x)  is  stronger  than  5(2) — conversely,  q{x)  is  weaker  than  p(x) — if  p  is  more  re¬ 
strictive  than  q,  i.e.  Vx  [p(x)  =►  9(z)]. 
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logical  relationship  e.g.  ==»,  <=,  <=^,  to  F.  For  example,  we  might  want  to  reason 
forward  {=>)  from  F  to  find  a  consequent  ^  whose  free  variables  are  a  subset  y  of  x 
satisfying 

Vx  [/!(£)  ==>(F(x)=i.^i(iO)].  (2) 

In  other  words,  we  try  to  find  a  necessary  condition  <(>  on  F  under  assumptions  A{x). 

Similarly,  given  A{x)  and  a  source  expression  e(x),  we  might  want  to  find  another 
expression  6{‘^  that  satisfies  some  syntactic  constraints  and  satisfies  some  comparison 
relation,  e.g.  <,  >,  =,  C,  with  e.  For  example,  a  lower  bound  0  for  e  over  variables  y 
satisfies: 

Vx  [>l(x)  =}«  e(x)  >  ^(jT)].  (3) 

In  the  context  of  directed  inference,  the  logical  relationship  {=^,. .  )  or  the  com¬ 
parison  relation  (<,...)  specifies  the  direction  of  the  inference.  For  any  particular 
direction,  there  is  a  tension  between  syntactic  simplicity  and  semantic  strength  of  the 
desired  formula.  For  example,  true  is  the  simplest  necessary  condition  for  a  given  F, 
but  is  too  weak;  similarly,  F  itself  is  as  strong  as  possible,  but  it  isn’t  any  simpler 
than  F.  We  have  developed  an  inference  engine  called  Rainbow  [32]  that  finds  for¬ 
mulas  and  expressions  optimizing  a  heuristic  measure  of  simplicity  and  strength.  For 
algorithm  design  purposes,  one  seeks  an  expression  that  optimizes  execution  efficiency 
and  semantic  strength.  Fortunately,  syntactic  simplicity  and  execution  efficiency  are 
correlated  in  the  examples  that  follow. 

In  general  we  specify  an  inference  as  follows: 

Assumptions 
Source 

Inference-direction 
Target-constraints 
Cost-function 

The  target-constraints  express  conditions  on  the  s^fitactic  form  of  the  desirable  in¬ 
ferred  term  or  formula  T.  The  keyword  varset  denotes  the  set  of  free  variables  in  T 
which  we  may  want  to  restrict  to  a  certain  subset. 

The  problem  of  finding  the  efficient  $  in  (1)  can  be  specified  as  follows. 


A\,  A2,  . . . ,  An 
S 

varset  C  {. . .}  A  ... 
syntactic  simplicity  -f  . . . 


Assumptions 

Source 

Inference-direction 
Target-  constraints 
Cost-function 


A(x) 

3  z  [z  e  r  A  0(x,z)] 
varset  C  {x,f} 

syntactic  simplicity  -f  semantic  strength 


For  example,  in  the  array  search  problem  above,  the  goal  is  to  find  an  efficient  test 
$(x,/,u,5)  satisfying: 
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Assumptions 

Source 

Inferen  ce-  di  rection 
Target-constraints 
Cost-function 


sorted{S) 

3  i  [i  6  [/ . .  u]  A  5(t)  =  i] 
varset  C 

syntactic  simplicity  -h  semantic  strength 


Our  system  derives  the  formula  S(/)  <  x  <  S(u).  Incorporating  this  test  and  split-in¬ 
half  into  the  subspace  generator  template  yields  the  binary  search  algorithm.  This 
algorithm  requires  time  O(log(suc(5))),  whereas  a  naive  generate-and-test  algorithm 
requires  time  0{$ize{S)). 


2,3  Program  Optimization  and  Finite  Differencing 

An  expensive  computation  E{x)  on  dependent  variables  x  can  be  simplified  by  tak¬ 
ing  advantage  of  context  Context  here  means  the  invariant  assertions  that  can  be 
assumed  to  hold  at  some  point  in  a  program,  and  the  values  that  have  b  en  com¬ 
puted  and  saved.  In  these  cases,  the  directed  inference  system  can  be  instructed  to 
find  a  more  efficient,  specialized  expression  that  is  equal  to  £(i),  given  the  context 
assumptions.  The  role  of  context  in  optimization,  and  specialization  transformations 
that  make  use  of  context,  have  been  studied  in  [29]. 

For  example,  if  the  expression  E  contains  a  subexpression  that  has  already  been  (or 
could  be)  computed  and  bound  to  a  variable,  then  a  common-subexpression  elimina¬ 
tion  transformation  allows  the  variable  to  be  used  in  place  of  the  subexpression  in  E. 
More  formally,  the  expression  /(y)  in  /f(Fi(/{t7),Xi),F2(/(yl)X2))  can  be  lambda 
abstracted,  resulting  in  let  z  =  /(y)  in  H{E\{z^xx),E2{z,X2)). 

A  similar  optimization  opportunity  arises  if  y  is  only  an  incremental  modification  of 
X,  and  E{x)  has  already  been  calculated.  In  this  case,  it  is  often  possible  to  calculate 
E{y)  given  x,  y,  and  E{x)  more  efficiently  than  it  is  to  calculate  E{y)  just  given  y.  An 
instance  of  this  opportunity  that  is  exploited  in  conventional  compilers  is  the  strength 
reduction  optimization.  One  example  of  this  optimization  transforms  a  multiplication 
by  a  constant  e.g.  E{y)  —  cy,  where  y  =  x  +  1  and  E{x)  has  already  been  calculated, 
to  an  addition  of  the  constant,  i.e.  E{y)  =  E{x)  +  c.  Another  example,  this  time  on 
the  sequence  datatype,  transforms  the  calculation  size{y),  where  y  =  appendix,  a),  for 
some  element  a,  and  where  stze(x)  has  already  been  calculated,  into  the  calculation 
siz€{y)  —  stze(x)  -f-  1.  Notice  the  latter  transformation  has  changed  a  linear  time 
computation  to  one  of  constant  time.  In  general,  for  an  incremental  update  C/(x),  we 
try  to  transform  E{U{x))  into  the  computation  Ev{x,  E(x)),  for  some  efficient  Ev- 

Function  abstraction  isolates  the  body  of  a  function  /(xi,. . .  ,Xn)  from  the  context 
set  up  in  the  functions  that  call  it.  In  a  purely  applicative  setting,  the  context  that 
an  expression  J5(ii, . . .  ,i„)  is  exposed  to  within  a  function  /  is  determined  solely 
by  the  bindings  of  /’s  parameters  and  the  bindings  of  local  variables.  However, 
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there  is  a  transformation  that  caa.  esDpose  E  to  the  •oactexl  of  the  functions  that 
call  /.  This  transformation  adds  &mrw  paramtiler-  say  c,  to  f's  parameter  list  (now 
/(xi, . . .  ,x„,  c)).  The  new  parameto  c  will  be  majTiXainod  equal  to  E.  Any  function  g 
that  contains  a  call  to  /,  say  the  call  is  must  now  supply  E{xx,. . .  ,Xn); 

i.e.,  the  call  must  be  changed  to  g(Ui,. . . ,  Un,F{U\,.  ■ . ,  Un))-  VVe  also  assert  within 
/  that  c  =  £'(xi,. . .  ,in)-  Now  that  the  expression  E  has  been  exposed  to  the  context 
set  up  in  5,  it  may  be  possible  to  simplify  it.  This  transformation  could  be  expressed 
as  a  composition  of  unfold,  abstract,  simplify,  and  fold  steps  as  in  [29j. 

A  particularly  important  case  of  this  transformation  is  when  /  calls  itself,  and 
Ux,. . .  ,Un-,  are  incremental  modifications  to  In  this  case,  application  of 

the  transformation  results  in  exposing  the  E  computation  to  a  context  containing  the 
value  of  the  E  computation  on  similar  values.  Such  finite  dj^ercnctn^  optimizations 
[22]  can  achieve  significant  space  and  time  savings  when  they  occur  within  loops  or  re¬ 
cursion,  because  some  efficiency  is  gained  each  time  /  is  called.  The  finite  differencing 
optimization  relies  on  algebraic  properties  of  E  and  the  incremental  modifications. 
We  use  directed  inference  to  express  (in  the  single  variable  case)  E{U{x))  equivalently 
as  Eu{x^  E{x)).  The  finite-differencing  program  transformation  scheme  used  in  this 
paper  is  illustrated  informally  below.  It  shows  how  the  definitions  for  functions  /  and 
g  would  be  changed. 


g(y)= 

g(y)= 

f(P) 

iiV,E{V)) 

f(i)= 

f(x,c)= 

assert  c  =  ^(x)  in 

E{x) 

c 

mx)) 

f{U{x),Eu{x,c)) 

Similar  finite-differencing  transformations  expressed  using  second-order  patterns  have 
been  given  in  [2]. 

The  MEQ  system  at  Kestrel  [5]  performs  finite  differencing  transformations  in  an 
imperative  setting.  The  optimization  scheme  we  employ  in  this  paper  simplifies  ex¬ 
pensive  expressions  within  recursive  functions,  as  <Iescribed  above.  We  are  working 
to  develop  tools  that  automatically  locate  the  expensive,  incrementally  computable 
expressions.  At  present,  the  programmer  indicates  the  expressions  to  be  maintained. 

Often,  the  expression  Eh  that  incrementally  computes  the  next  value  has  itself  some 
expensive  operations  that  must  be  themsel\»ef  maintained.  Parameters  holding  these 

$ 


intermediate  computations  are  also  added  to  the  recursive  function  and  maintained. 

Some  expressions  do  not  at  first  appear  to  be  incrementally  computable,  but  can 
be  rewritten  :»  equivalent,  incrementally  computable  expressions  [22j.  For  example, 
a  standard  technique  for  incrementally  maintaining  the  expression  Vx  [/^(x)]  is  to 
reforn  ■  ate  it  equivalently  as  size({x  j  -iP(x)})  =  0.  That  is,  the  expression  that 
is  true  if  every  x  satisfies  F(x)  is  reformulated  as  the  expression  that  is  true  only 
when  the  number  of  elements  for  which  ~'P{x)  is  zero.  The  number  of  elements  x  for 
which  -’F(x)  can  more  often  be  incrementally  maintained  than  the  original  quantified 
expression. 

After  the  program  has  been  transformed  to  maintain  intermediate  expressions  in 
parameters,  it  often  turns  out  that  some  of  the  dependencies  of  expressions  on  others 
have  been  removed.  Thus,  some  of  the  variables  may  be  unused,  or  dead,  hence  they 
may  be  dropped  from  the  parameter  lists  of  the  function.  The  variables  that  are  dead 
can  be  detected  by  data  flow  analysis  [22\ 


2.4  Data  Structures 

Another  step  in  the  algorithm  design  process  is  the  development  of  representations 
for  each  of  the  abstract  data  types  in  the  algorithm.  Compilers  typically  provide  a 
standard  implementation  representation  for  each  type  in  their  programming  language. 
However  as  the  level  of  the  language  rises,  and  higher-level  data  types,  such  as  sets, 
sequences,  and  mappings,  are  included  in  the  language,  or  as  users  specify  their  own 
abstract  data  types,  standard  representations  cease  being  satisfactory.  The  difficulty 
is  that  the  higher-level  datatypes  can  be  implemented  in  many  different  ways:  e.g. 
sets  may  be  implemented  as  lists,  arrays,  trees,  etc.  Depending  on  the  mix  of  opera¬ 
tions,  their  relative  frequency  of  invocation,  and  size  information,  one  implementation 
may  be  much  better  than  another.  Thus  no  single  default  implementation  will  give 
good  performance  for  all  specifications  containing  the  abstract  type.  Work  on  data 
structure  generation  and  selection  for  very-high-level  languages  attempts  to  deal  with 
these  problems  [31,4]. 

Kotik’s  DSS  system  [9,19]  can  generate  for  a  given  very-high-level  data  type  a  large 
space  of  possible  alternative  representations  expressed  in  terms  of  standard  high  level 
datatypes;  e.g.  integers,  arrays,  records.  These  alternative  representations  are  gen¬ 
erated  by  composing  together  small,  well  known  datatype  conversions  (cf.  [18]).  For 
example,  a  set  of  elements  may  be  represented  as  a  sequence  of  those  elements  {re¬ 
peated  or  not),  or  a  set  may  be  represented  as  a  characteristic  mapping;  a  mapping 
may  be  represented  as  a  set  of  pairs,  or  as  the  composition  of  two  other  mappings; 
a  sequence  may  be  represented  as  a  mapping  from  indices  to  the  elements,  or  as  a 
list.  The  DSS  system  was  able  to  construct  a  representation  such  as  hash  table  whose 
buckets  are  lists  for  the  set  datatype,  just  by  composing  these  well-known  conversions. 
Once  some  representation  has  been  chosen,  the  program  can  be  transformed  into  one 
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using  the  standard  datatypes. 


Recent  work  [10]  has  extended  DSS  rules  so  that  their  applicability  conditions  lake 
into  account  performance  considerations.  The  representation  decisions  depend  on  the 
operations  performed  on  it  and  their  frequency  of  occurrence.  For  example,  the  main 
sequence  operations  in  the  searching  program  above  are  assigning  the  sequence,  and 
accessing  a  random  element — the  latter  being  repeated  many  times.  This  suggests  an 
array  implementation,  because  random  access  takes  constant  time.  [30]  shows  how  a 
sequence  may  be  implemented  as  a  stack,  and  hence  as  an  array  with  a  pointer  to 
the  top,  if  only  certain  of  the  sequence  operations  are  used,  and  subsequences  are  not 
referenced.  This  applies  to  our  derivation,  as  discussed  in  Section  3.6.  The  subject 
of  copy  elimination,  e.g.  how  to  decide  whether  parameters  need  not  be  copied  when 
passed,  or  whether  certain  actions  can  be  performed  in-place,  has  been  discussed 
in  [12],  We  are  refining  a  theory  that  guides  the  DSS  system,  but  do  not  have  a 
comprehensive  theory  as  yet. 


3  Example:  Scheduling  Jobs  with  Deadlines  on  a 
Single  Processor 


We  illustrate  the  concepts  and  systems  discussed  above  by  stepping  through  the 
derivation  of  an  optimization  algorithm.  All  of  the  steps  in  this  derivation  are 
correctness-preserving  so  that  the  final  code  is  guaranteed  to  correctly  solve  the 
problem  described  by  the  initial  specification.  Furthermore  most  of  the  program¬ 
ming  knowledge  used  in  the  derivation  is  understood  web  enough  that  the  steps  are 
formally  motivated.  We  believe  that  this  derivation  could  be  produced  with  very  little 
guidance  from  a  human  developer.  Most  of  the  derivation  steps  can  be  performed  by 
research  systems  currently  running  at  Kestrel  Institute. 


3.1  Specification 

Suppose  that  we  wish  to  schedule  a  set  of  jobs  on  a  processor  subject  to  some  con¬ 
straints  on  the  order  in  which  jobs  can  run.  Further  suppose  that  each  job  completes 
in  unit  time,  that  each  job  has  a  deadline,  and  that  we  wish  to  minimize  the  number 
of  jobs  that  fail  to  complete  before  their  deadlines.  If  we  define  a  schedule  to  be  an 
ordering  of  a  given  set  of  jobs  that  satisfies  some  given  constraints,  then  this  is  an 
optimization  problem  where  the  feasible  space  is  the  set  of  schedules,  and  the  cost 
function  is  the  number  of  jobs  in  a  schedule  that  fail  to  complete  before  their  deadline. 

Formally,  the  feasible  space  of  schedules  can  be  specified  as  follows. 
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SCHEDULES(Jo65  :  set{J OB),  Precedes  :  h\nTe\{JOB,JOB))  :  set(seq(  JOB))  = 
{5  I  5  €  seq( J065)  A  elemenis-of  (S)  =  J obs  A 

€  Jobs  [  Precedes(ji,j2}  =>  index{S,ji)  <  tnJeT(5,  jj)]} 


Here  Jobs  is  the  set  of  jobs  that  we  wish  to  schedule.  The  variable  Precedes  is  a 
binary  relation  over  Jobs  and  is  assumed  to  be  a  partial  order.  The  feasible  space 
SCHEDULES( Jo6s,  Precedes)  is  defined  to  be  the  set  of  all  sequences  5  of  Jobs 
whose  elements  (a  multiset)  are  exactly  Jobs  and  such  that  the  ordering  of  jobs  in  S 
is  consistent  with  the  Precedes  relation.  Following  is  a  specification  of  the  optimal 
scheduling  problem,  called  SWD  (Scheduling  With  Deadlines). 


SWD(Jo6s  :  set{J OB),  Precedes  :  h\nre]{  JOB,  JOB), 
Deadline  :  JOB  — ►  natno)  :  seq(JOB)  = 
minimum(C,  SCHEDULES(  Jobs,  Precedes)) 


The  cost  function  C  is 

C{Jobs,  Precedes,  Deadline,  S)  =  size{{j  \j  €  Jobs  A  Deadltne{j)  <  index{S,  j))). 


The  input  Deadline  is  a  mapping  from  jobs  to  deadline  times  (represented  as  natural 
numbers). 


3.2  Development  Strategy 

As  discussed  earlier  the  o%erall  development  strategy  is  to  retrieve  from  a  library  a 
standard  subspace  generator  for  the  output  domain  of  SW’^D  (sequences  over  a  finite 
domain),  then  to  specialize  it  so  that  only  feasible  solutions  (schedules)  are  gener¬ 
ated,  and  then  to  further  specialize  it  so  that  only  optimal  solutions  are  generated. 
Interleaved  with  this  specialization  activity  are  code  optimization  steps.  We  conclude 
with  some  consideration  of  the  design  and  representation  of  data  structures  in  the 
generator. 


3.3  Algorithm  Design 

The  first  step  is  to  select  a  standard  subspace  generator  that  can  enumerate  a  superset 
of  the  feasible  space  SCHEDULES(Jo6s,  Precedes).  We  select  a  generator  S{D)  for 
sequences  over  type  D  that  works  as  follows  (see  also  Figure  1):  Each  subspace 
is  described  by  a  sequence  (called  ps  here,  an  abbreviation  of  “partial  schedule’’) 
denoting  the  maximal  common  prefix  of  sequences  in  the  subspace.  Clearly  the  empty 
sequence  describes  the  whole  type  seq(D)  and  thus  it  is  the  descriptor  for  the  root 
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node  (of  the  subspace  tree).  A  descriptor  ps  is  split  into  descriptors  of  subspaces  by 
appending  a  single  element.  For  example,  if  we  want  to  enumerate  sequences  over 

•  {0,1,2}  then  the  subspace  descriptor  [2,1],  w'hich  denotes  all  sequences  beginning 
with  a  2  followed  by  a  1,  is  split  into  the  descriptors  [2,1,0],  [2, 1, 1],  and  [2,1,2]. 

This  generator  is  specialized  by  incorporating  some  of  the  constraints  of  SCHEDULES 
into  the  subspace  splitting  operation.  This  is  done  by  developing  a  test  that  can 

•  determine  that  a  subspace  descriptor  cannot  describe  any  feasible  solutions.  More 
precisely  we  derive  a  necessary  condition  of 

3  S  [S  extends  ps 

A  elements- of  {S)  =  Jobs 

®  ^  Jobs[Precedes{jiyj2)  ==^  index{S.,ji)  <  72)]] 


over  the  variables  {Jobs,  Precedes, Deadline, ps}.  In  words,  we  derive  a  necessary 
condition  on  the  existence  of  an  extension  5  to  subspace  descriptor  ps  that  is  feasible, 
i.e.,  an  extension  that  has  all  the  jobs  of  Jobs  and  no  ordering  constraint  is  violated. 
A  derivation  such  as  that  in  Figure  2  results  in  the  filter  <&(ps); 
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S  extends  ps  4=^  S  —  concat{ps,qs)  ^ 

elements-of{S)  =  Jobs  - — ^  elements~of  {concat{ps,qs))  —  Jobs 

I 

elements- of  (ps)  fej  elements-of  {qs)  =  Jobs 

^  I 

elements-of  (ps)  C  Jobs  elements-of  (qs)  =  Jobs  —  elements-of  (ps) 

Vii,j2  £  Jobs  [  Precedes(jiJ2)  =>  index{S,ji)  <  index{S,j2)] 

case  analysis 

Vji,jf2  I  ii  €  elements-of  (ps)  A  j2  6  elements-of  (ps)  A  PTecedes(j\,j2) 
in</ei{5,  ji)  <  tn<fci(5,  j2)] 

k. 

Vji,j2  (ii  €  J065  —  elements-of  (ps)  A  jj  €  elements-of  (ps)  ■=>  -'Pr€cedes{jt,j2)] 
Figure  2:  Deriving  a  filter  via  forward  inference 


elements-of  (ps)  C  Jobs  A 

Wji,j2  I  ji  €  elements-of  (ps)  A  72  €  elements-of  (ps)  A  Precedes(ji,j2) 

=»  index(S,ji)  <  index(S,j2)]  A 

Vii,j2  lii  €  J065  —  elements-of  (ps)  A  €  elements-of  (ps)  =»  -’Prccc<fes(ji,  J2)] 

With  this  filter  we  have  the  first  version  of  our  target  algorithm,  shown  in  Figure  3. 
This  gives  us  the  rough  structure  of  the  target  algorithm.  Before  proceeding  there  is 
a  simple  but  powerful  simplification  that  we  C2ui  perform.  Notice  that  the  filter  ^(ps) 
holds  invariantly  on  entry  to  the  recursive  function  SCHEDULESl_aux(p5),  yet  the 
straightforward  implementation  of  SCHEDULESl_aux(ps)  would  test 
^(append(ps,  a)).  We  set  up  the  directed  inference  task  of  simplifying  ^(append(ps,  a)) 
under  the  assumption  of  $(ps)  (see  Figure  4)  with  the  result  <^{ps,a): 


Vj  6  Jobs  —  elements-of  (ps)  [->Preccde5{j,  a))  A  a  €  Jobs  —  elements-of  (ps). 


SCHEDULESl(j£)65,  Precedes,  Dea<i/me)= 
if  $([  ])  then  SCHEDULESl-aux([  ]) 


SCHEDULESl-aux(ps)= 
assert  $(p5) in 
if  st2:e(ps)  =  siz€{Jobs) 
then  {ps} 

else  (J  SCHEDULESl-aux(appencl(ps,a)) 

a  €  Jobs  A 
^{append{ps,a)) 


Figure  3;  Subspace  Generator  for  SCHEDULES  -  Initial  Version 


Inference-direction  (logical  equivalence) 
Assume  ^(p^)  A  a  €  Jobs 

Source  ^{append{ps,a)) 


1.  elements- of{append{ps., a))  C  Jobs 

<=>  {elements-of  {ps)  -1-  a)  C  Jobs 
•<=^  a  e  {Jobs  —  elements- of  {ps)) 

2.  case  analysis  results  in  true 

3.  case  analysis  results  in  Vj  e  Jobs  —  elements-of  {ps)  [-^Precedes{j,a)] 


Figure  4:  Simplification  of  9{append{ps,a)) 


SCHEDULES2(  Jo63,  Precedes,  Deadline)^ 

SCHEDULES2-aux([]) 

SCHEDULES2.aux(ps)= 
assert  ^(ps)  in 
if  size{ps)  =  size{Jobs) 
then  {ps} 

else  [J  SCHEDULES2-aux(appen<f(p.<>.  n )  j 

a  €  Jobs  —  elements- of  (ps) 

Vj  €  Jobs  —  elements-of  (ps)  {•-'Prece«ies(ji,  a)] 

Figure  5:  Simplified  Generator  for  SCHEDULES 


Using  <f){ps,a)  in  place  of  ^{append{ps,a))  results  in  a  large  savings  of  time  per  recur¬ 
sive  call.  This  optimization  is  related  to  finite  differencing  since  we  are  incrementally 
maintaining  an  invariant  relation  but  different  in  that  the  invariant  does  not  in¬ 
volve  initializing  and  updating  a  data  structure.  The  simplified  generator  appears  in 
Figure  5. 


3.4  Finite  Differencing  Optimization 

We  now  apply  finite  differencing  in  order  to  further  refine  and  optimize  SCHEDULES2. 
Note  that  the  loop  in  the  recursion  involves  enumerating  over  the  set 

{a  I  a  6  Jobs  —  elements-of  (ps)  A  Vj  €  Jobs  —  elements-of  (ps)[-iPrecedes(j,  a)]} . 

We  wish  to  reduce  the  complexity  of  computing  this  set  by  creating  some  intermediate 
data  structures  and  maintaining  their  values  incrementally.  We  can  pull  out  from  this 
expression  the  following  invariants  to  maintain: 


Free-set  =  Jobs  —  elements-of  (ps) 

Test  =Xa.Vj  €  Free^et(ps)[->Precede3(j,a)] 
Minuet  =  {a  |  a  €  Free-set  A  T cst(a)} 


As  mentioned  in  Section  2.3,  the  Test  expression  may  be  maintained  by  reformulating 
it  in  an  equivalent,  incrementally  computable  form.  In  this  case  we  replace  Test  by 


size({j  I  j  €  Free-set(ps)  A  Precedes(j,a)})  =  0. 


SCHEDULES3(  Jo65,  Precedes,  Deadline)— 

SCHEDULES3_aux([],  ps.SizeJnit,  Free^etJnit, 

PrecjmapJnit,  SizeJnapJnit,  Minuet Jnit) 

SCB.ED\JLESd-&ux{ps,ps^ize,Free^et,Precjmap,Sizejmap,  Min^et)= 
assert  $(ps)  A  pssize  =  size{ps) 

A  F reejset  —  Jobs  —  elements~of  (ps) 

A  Prec-map  =  Aa.{j  j  j  €  Free^et  A  Precedes{j,  a)} 

A  Sizejnap  =  \a.size{Precjnap{a)) 

A  Minuet  =  {a  1  a  €  Freeset  A  SizejTiap[a)  =  0}  in 
if  ps-size  =  sizt{Jobs) 
then  {ps} 

else  reduce(U,  {SCHEDULES3-aux(appeRd(ps,a),  A-ps_size, 

A-Free-seZ,  APrec-map, 
ASizejnap,  AMin^ei) 

I  a  6  M inset}) 


Figure  6:  SCHEDULES  plus  Finite  Differencing  Structure 


The  resulting  set  of  data  invariants  to  maintain,  called  ({ps),  is 


pssize  =size{ps) 

Freeset  =Jobs  —  elements- of{ps) 

Precjmap  —Xa.{j  \j  €  Freeset  A  Precedes{j ,  a)} 
Sizesnap  =Xa.size(Precjmap{a)) 

Minset  =  {a  j  a  €  Freeset  A  Sizejmap{a)  =  0} 


The  challenge  is  to  maintain  these  invariants  under  change  to  the  parameter  ps  in 
SCHEDULES2-aux  (they  also  depend  on  Jobs  and  Precedes  but  these  are  fixed 
parameters  and  so  we  treat  them  as  constants).  In  a  recursive  setting  we  must 
add  each  of  the  above  variables  as  new  parameters  to  the  recursive  function.  In 
effect  they  become  part  of  the  local  state  of  the  recursive  computations.  Figure  6 
shows  schematically  the  structural  changes  induced  by  our  attempt  to  maintain  the 
invariants  ((ps).  This  figure  is  schematic  in  that  it  only  indicates  where  initialization 
and  update  code  is  positioned  and  not  how  it  is  achieved. 

The  directed  inference  involved  in  deriving  the  initialization  and  update  code  for  the 
invariant  pssize— size{ps)  is  simple.  When  ps  is  initialized  to  (]  (the  empty  sequence), 
then  the  value  of  pssize  is  0.  To  derive  the  update  code  we  perform  equality¬ 
preserving  inference  on  the  source  term  size{append{ps,a))  under  the  assumption 
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psjsize  =  size{ps),  resulting  in  the  derived  term  pssize  4-  1.  Analogous  derivations 
for  the  initialization  and  update  code  for  the  invariant 

Siztjmap  =  Xb.siz€{Precjnap{b)) 


are  given  in  Figure  7. 

Incorporating  all  of  the  initialization  and  update  code  results  in  the  refinement  of 
SCHEDULES3  to  SCHEDULES4  in  Figure  8.  Note  however  that  in  SCHEDULES4 
we  can  eliminate  a  number  of  dead,  or  unused,  variables  and  their  corresponding 
update  code.  The  result  is  SCHEDULES5  in  Figure  9,  an  efficient  generator  of 
feasible  objects. 


3.5  Incorporating  the  Cost  Function 

We  now  further  specialize  the  generator  so  that  it  only  enumerates  optimal  cost 
objects,  as  described  in  Section  2.1.  Generally  the  technique  is  analogous  to  that 
used  for  constraining  the  generator  to  enumerate  only  feasible  solutions:  we  derived 
a  necessary  condition  on  the  existence  of  feasible  objects  in  a  subspace.  We  derive  a 
necessary  condition  on  the  existence  of  optimal  solutions.  In  [34]  we  show’  that  several 
common  pruning  techniques  such  as  lower  bound  pruning  and  dominance  relations 
can  be  derived  in  this  way.  Here  we  focus  on  the  derivation  of  a  lower  bound  function 
for  SWD  and  how  it  can  be  used  to  improve  the  search  process  of  SCHEDULES.  In 
particular  we  derive  a  lower  bound  on  the  cost  function 

si>e({j  I  j  €  Jobs  A  Deadline{j)  <  index{S,j)}). 

The  derivation  in  Figure  10  results  in  a  bound  that  is  the  sum  of  (1)  the  number  of 
jobs  in  the  partial  schedule  ps  that  have  already  missed  their  deadlines  and  (2)  the 
number  of  jobs  not  in  ps  that  have  already  missed  their  deadlines  (i.e.  their  deadline 
lies  between  1  and  size(ps)).  Another  term  which  we  have  derived  manually  (but  not 
presented  in  the  figure)  would  measure  the  number  of  jobs  J  not  yet  in  ps  that  could 
not  possibly  meet  their  deadline  (because  too  many  predecessors  must  be  executed 
before  j’s  earliest  possible  execution  time).  This  additional  term  would  improve  the 
bound  and  thus  improve  performance  of  the  search  procedure.  The  low’er  bound 
function  can  be  maintained  incrementally  just  as  we’ve  done  for  ^(ps)  and  the  finite 
differencing  variables.  The  initialization  and  update  code  are  derived  in  Figure  11. 

Exploiting  the  lower  bound  function  gives  us  a  classic  branch-and-bound  algorithm. 
It  records  the  best  schedule  found  so  far  in  the  search  process  and  its  cost  u6,  and 
deletes  from  consideration  any  subspace  whose  lower  bound  is  not  less  than  ub.  To 
use  the  lower  bound  function  incrementally  we  must  again  add  a  new  parameter  to 
the  parameter  list  of  the  recursive  function  in  SCHEDULES.  In  addition  we  convert 
to  iterative  form  so  that  we  can  more  easily  maintain  global  variables  that  record  the 
least  cost  solution  found  so  far  and  its  cost  (see  Figure  12). 
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SizejTiap—  Xb.size{{j  \  j  €  Jobs  —  elements-of  (ps)  A  Precedes{j^b)}) 
Initialization  ps  <-  ( ] 

Assume 

Source  Xb.size{{j  [  j  6  Jobs  —  elements-of {[])  A  Precedes{j,b)}) 

~Xb.size{{j  \j  €  Jobs  A  Precedes{j,b)}) 

Increment  ps  <—  append{ps^a) 

Assume  Prec-map=  Xb.{j  \  j  £  Freeset  A  Precedes{j,b)} , 

APrec^ap  =  Xb.{if  Pr€cedes{a,  b) 

then  Precjmap{b)  —  a 
else  PrecJnap{b)), 

Sizejriap=  Xb.size{Precjmap{b)) 

Source  Xb.size  (APrec-map) 

=Xb.size(i{  Precedes{a,b) 

then  Precjmap{b)  —  a 
else  Prtc-map{b)) 

=A6.(if  Precedes{a,  b) 

then  size{Precjnap{b)  —  a) 
else  size{Precjmap{b)) 

=A6.(if  Precedes{a,  b) 

then  Siz€jnap{b)  —  1 
else  Sizejnap{b)) 


Figure  7;  Incremental  Maintenance  of  Size^map 
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SCHEDULES4(Jo65,  Precedes,  Deadline)— 
let  ps^ize  =  0 

let  Free^et  =  Jobs 

let  Prec-map  =  ^b.(J  (  J  €  free^et  A  Precedes{j,  b)} 
let  Sizejnap=  \b.size{Precjnap{b)) 

let  Minset  =  {a  |  a  6  free^et  A  Size-HLap{a)  =  0} 
SCHEDULES4_aux([  ], ps^ize,  Free^et, 

Prec-map,  SiztJmap,  Minuet) 


SCHEDULES4-aux(ps,ps_5i2e,  Free-set,  Precjnap,  SiztJmap,  Minset)— 
assert  $(ps)  A  ^(ps)  in 
if  pssize  =  siz€{Jobs) 
then  {ps} 

else  reduce  (U,  {SCHEDULES4-aux(flppen<i(p5,  a), 

pssize  -f  1, 
freesei  —  a, 

A  b.  (if  Precedes{a,  b) 

then  Prec-map{b)  —  a 
else  Precjmap{b)), 

A  6.(if  Precedes{a,b) 

then  Size.map{b)  —  1 
else  Sizejriap{b)), 

{Minset  U  {6  |  Precedes{a,  b)  A  Sizejmap{b)  =  1})  —  o) 
I  a  €  Minset)) 


Figure  8:  SCHEDULES  with  Finite  Differencing 
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SCHEL  JLES5( Jo6s,  Precedes^  Deadline)— 
let  ps^ize  =  0 

let  Sizejrnap  =  Xb.size{{j  \j  €  Jobs  A  Preccifes(j,  6)}) 
let  Min^iet  =  {a  1  a  6  free^et  A  Sizejnap{a)  =  0} 

SCHEDULES5-aux([  ],ps-si2e,  Sizezmap,  Minuet) 

SCHEDULES5-aux(p5,  p5_522c,  Size  jnap^  Min  jset)= 
assert  $(p5)  A  ^(ps)  in 
if  ps^ize  =  size{Job$) 
then  {p3} 

else  reduce(U,  {SCHEDULES5-aux(appen(i(ps,a),ps_si2e  +  1, 

A  b.  (if  Precedes(a,  b) 

then  Sizejmap{b)  —  1 
else  Sizejnap(b)), 

(Minsei  U  {5  |  Precedes{a,  b)  A  Sizejrnap{b)  =  \])  —  a] 
1  a  G  Minset}) 

Figure  9:  SCHEDULES  with  dead  variables  removed 


Another  reason  for  converting  to  iterative  form  is  to  make  the  recursive  calls  into 
explicit  data  structures;  this  allows  us  to  more  flexibly  specify  control  strategies.  The 
data  structure  PQ  is  specified  as  an  abstract  data  type  known  as  a  priority  queue  (or 
agenda).  Generally  priority  queues  represent  sets  of  objects  with  associated  priorities. 
The  operations  include  InitJ^Q  which  creates  an  empty  queue,  Insert  which  adds 
an  object  to  the  queue  and  assigns  it  a  priority,  and  Select  which  extracts  that  object 
in  the  queue  with  highest  priority.  Priority  queues  can  be  used  for  controlling  search 
processes  by  letting  the  objects  be  representations  of  tasks  and  letting  the  priority  of 
a  task  reflect  the  desired  search  strategy.  For  example,  to  achieve  a  best-first  search, 
the  priority  on  a  task  should  be  the  value  of  the  lower  bound  function.  Breadth-first 
and  depth-first  search  can  be  achieved  by  basing  the  priority  of  a  subspace  on  its 
depth  in  the  search  tree.  At  this  point  we  leave  the  specification  of  the  priority  open. 


3.6  Data  Structure  Representation 


The  next  step  in  the  design  process  is  to  develop  representations  for  each  of  the 
abstract  data  types  in  the  algorithm.  The  representation  decisions  for  a  variable 
depend  on  the  operations  performed  on  it  and  their  frequency  of  occurence.  Consider 
the  subspace  descriptor  ps  which  denotes  a  partial  schedule: 
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Inference-direction  > 

Target-characteristics  varsei  C  {Jobs, Precedes,  Deadline, ps} 

Assume  S  extends  ps 

A  5  =  concat{ps,qs) 

A  elements-of  (s)  =  Jobs 
^^ps)  A^(ps) 

Source  sizt{{j  \j  €  Jobs  A  Deadline{j)  <  index{S,j)]) 

si2e{{j  I  j  6  Jobs  A  Deadline{j)  <  indei(5,j)}) 

=si2e({j  I  j  G  elements- of {S)  A  Deadline{j)  <  index{S,j)}) 

=size({j  \j  €  elements- of {concat{ps,qs))  A  DeadHne{j)  <  index{S,j)}) 

=sire({j  1  {j  €  elements-of  {ps)  W  j  €  elements-of{qs))  A  Deadline[j)  <  indc.r{S.j)}] 
=st2e({j  1  j  €  elements- of  (ps)  A  DeadHne{j)  <  index{S,j)) 

{i  1  i  €  elements-of  {qs)  A  Oeadline{j)  <  index{S,j)}) 

=si2e({j  I  j  G  elements- of  {ps)  A  Deadline{j)  <  index{S,j))) 

-\-$ize{{j  I  j  G  Jobs  —  elements-of  {ps)  A  Deadline{j)  <  mdex(5,  j)})) 

>  st2e({j  I  j  G  elements-of  {ps)  A  Deadline{j)  <  index{S,j)]) 

-|-si2c({j  I  j  G  Jobs  —  elements- of  {ps)  A  Deadline{j)  <  st2e(ps)})) 


Figure  10:  Deriving  the  Lower  Bound  Function 


I 
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lb{ps)  =  sue({j  I  j  6  elements-of  (ps)  A  Deadline{j)  <  index{S,j))) 


Initialize:  ps  [] 

Source  /6([]) 

=5t2’c({j  1  j  6  elements-of  {[  ])  A  . . .}) 

=0 

Increment:  ps  ^  append{ps,a) 

Inference-direction  = 

Assume  lb{p$)  =  size{{j  [  j  €  elements- of  (ps)  A  Deadline{j)  <  index{psj)]) 

Source  size({j  \j  €  elements-of  {app€nd{ps, a))  A  Deadline{j)  <  xndex{append{ps,(i  ].  j  ] 

size{{j  \j  €  elements-of  {append{ps, a))  A  Deadline{j)  <  index{append{ps,(i).  j)) 

=  size{{j  \j  €  elements-of  (ps)  A  Deadline(j)  <  index(ps,j)}) 

-|-size({j  I  J  =  a  A  Deadline{j)  <  index{append{ps,a),j))) 

=  lb{ps)  +  (if  Deadline{a)  <  size{ps)  +  1  then  1  else  0) 

Figure  11:  Incremental  maintenance  of  the  lower  bound  function 


SWD6(  Jo6s,  Precedes,  Deadline)^ 
let  solution  :  seq{ JOB)  =  [], 
lb  :  natno  =  0, 
ub  :  natno  =  maxint, 

Job^ize  :  natno  =  size{Jobs), 
ps  :  seq(  Jobs)  =  [  ], 
ps^size  :  natno  =  0, 

Sizejmap  :  {Jobs  —*  natno)  =  Xb.  size{{j  ( j  €  Jobs  A  Precedes{j,  i)}) 
let  Minuet  :  set{JOB)  =  {a  [  a  €  Jobs  A  Sizej7iap{a)  =  0}, 

PQ  :  Priority. Queue{seq{ JOB)  x  natno  x  {Jobs  — »  natno)  x  set{JOB)  x  natno 
=  InitJPQ] 

Insert{PQ,  {ps,ps.size,  Sizejmap,  Mindset,  lb}); 
while  nonemptyiPQ)  do 

begin 

{ps,ps.siz€,  Sizejnap,  Mindset,  lb)  <—  S€lect{PQ); 
if  lb  <  ub  then 

if  ps.size  =  Job-size 

then  %  record  best  solution  and  cost  found  so  far 
solution  *—  ps;  ub  *—  lb; 
else  enumerate  a  G  Min.set  do 
Insert{PQ,  {append{ps,a), 
ps.size  +  1, 

A6.(if  Pr€C€des{a,b) 

then  Sizejnap(b)  —  1 
else  5i2ej7iap(6)), 

(A/m-set  U  {6  |  Pr€cedes{a,b)  A  Siztjmap{h)  =  1})  —  o, 

16+  (if  Deadline{a)  <  ps.size  then  1  else  0))) 

end; 

solution 

end. 

Figure  12:  SWD  -  Iterative  Optimization  Version 


Figure  13;  A  Structure-Sharing  Representation  of  Sequences 


Opemtion 

Frequency 

append{ps.,a) 
solution  *-  ps 

once 

often 

occasionally 

A  standard  representation  for  sequences  is  linked  lists;  however,  this  representation 
is  expensive  for  ps  because  it  entails  copying  ps  every  time  the  append  operation  is 
performed,  A  better  representation  is  shown  in  Figure  13  where  alternative  versions 
of  ps  coexist  and  share  common  structure.  The  data  structure  ps  is  simply  a  pointer 
to  the  last  element  of  the  sequence.  In  this  representation,  initialization  and  append 
take  constant  time,  and  the  assignment  operation  takes  time  linear  in  the  size  of  ps 
(by  tracing  upwards  from  the  element  pointed  to  by  ps). 

This  representation  is  the  composition  of  two  data  type  conversions:  that  a  sequence 
may  be  represented  as  the  reverse  of  another  sequence,  and  that  a  sequence  may 
be  represented  as  a  linked  list.  The  facts  that  motivate  this  representation  are  that 
(1)  prepending  an  element  onto  a  sequence  does  not  require  copying  the  sequence 
(provided  that  random  modifications  to  the  sequence  are  not  performed),  and  (2) 
appending  an  element  onto  a  sequence  is  equivalent  to  prepending  the  element  onto 
the  reverse  of  the  sequence  (provided  that  the  reversed  sequence  is  reversed  again 
when  the  value  of  it  is  desired).  An  analogous  structure-sheu'ing  representation  can 
be  used  on  the  mapping  variable  Size.map. 
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On  the  other  hand,  if  a  depth-first  strategy  is  chosen,  then  ps  is  accessed  in  a  stack 
manner,  with  no  pointers  to  subsequences,  so  can  be  implemented  as  an  array  with 
a  top  pointer.  We  thus  see  that  the  context  of  use  of  a  data  object  affects  the  choice 
of  a  representation  for  the  data  object. 


4  Concluding  Remarks 


We  have  formally  developed  specification  SWD  into  algorithm  SWD6.  The  initial 
specification  was  a  concise  and  straightforward  definition  of  the  problem;  optimal 
scheduling  of  jobs  on  a  processor  under  precedence  constraints  and  deadlines.  It 
has  essentially  no  algorithmic  content.  The  derived  algorithm  is  much  longer  and 
more  difficult  to  understand,  yet  is  guaranteed  to  be  correct  with  respect  to  the 
specification. 

The  development  process  produced  a  series  of  increasingly  efficient  versions  of  the 
algorithm.  The  initial  specification  SWD  was  uncompilable  using  conventional  tech¬ 
niques.  The  initial  subspace  generator  searched  a  tree  with  0(n")  nodes  and  spent 
Oin*)  time  per  node  (where  n  denotes  the  number  of  jobs  to  be  scheduled).  Introduc¬ 
ing  the  filter  $  and  simplifying  it  reduced  the  number  of  nodes  searched  to  between 
0{n)  and  0(n!)  depending  on  the  strength  of  the  precedence  relation  Precedes^  and 
reduced  the  time  spent  per  node  to  0{n^).  Finite  differencing  optimizations  sub¬ 
stantially  reduced  the  constant  associated  with  the  time  spent  per  node.  Introducing 
the  lower  bound  function  and  its  incremental  computation  substantially  reduced  the 
number  of  nodes  searched  although  it  is  difficult  to  quantify  the  effect.  Finally  the  in¬ 
troduction  of  specialized  data  representations  for  the  data  structures  of  the  algorithm 
further  reduced  the  time  spent  per  node  to  between  0(n)  and  i9(nlogn)  depending 
again  on  the  strength  of  Precedes.  Since  the  nodes  can  be  processed  independent!} 
further  improvements  could  be  made  by  transforming  the  algorithm  for  execution  in 
a  parallel  environement. 

Experimental  systems  under  development  at  Kestrel  can  currently  support  most  of 
the  capability  needed  to  perform  the  derivation  of  SWD6.  The  directed  inferences  in 
this  paper  are  easily  handled  by  the  RaiNBOV.  II  inference  system.  The  CYPRESS 
II  algorithm  design  system  has  semiautomatically  produced  subspace  generators  for 
several  problems,  but  does  not  yet  support  the  optimization  structure  described  above 
(e.g.  derivation  and  use  of  the  lower  bound  function).  The  MEQ  (5)  finite  differencing 
system  has  produced  the  initialization  and  update  code  described  in  our  example,  al¬ 
though  in  a  slightly  different  format.  MEQ  allows  progranrmers  to  specify  constraints 
of  the  form  ^  =  E  and  it  combines  analysis,  table  lookup,  and  composition  to  obtain 
maintenance  code  for  c  with  respect  to  modifications  to  parts  of  E.  Initialization  and 
update  code  are  automatically  added  to  the  program  during  compilation.  The  DSS 
system  [19]  and  extensions  [10]  allow  limited  transformational  development  of  repre- 
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sentations  for  VHL  daia  structures  based  on  performance  criteria.  Some  of  the  data 
structure  representations  discussed  above  would  require  extensions  to  this  system. 
The  ReFINE^”^  language  is  well-suited  fw  expressing  the  initial  specification  SWD. 
Its  compiler  can  produce  executable  code  from  the  intermediate  forms,  although  they 
would  be  relatively  inefficient.  The  final  derived  algorithm  would  be  compiled  into 
efficient  COMMON  LiSP  code. 

We  have  not  yet  attempted  to  integrate  all  of  these  systems  and  develop  a  uniform 
interface  to  the  programmer.  Some  of  tJie  substantial  difficulties  with  integration  and 
interface  include: 

•  Explanation  -  Why  was  that  decision  made?  What  decisions  have  been  made 
so  far?  Vvhat  methods  are  available  for  achkreiiig  goal  G? 

•  Assistance  -  What  can  I  do  now?  What  shooM  1  do  no*? 

•  Assessment  -  How  well  am  I  doing?  Which  decision  is  better? 

•  Instruction  -  You  (the  computer’)  should  laio«r  x. 

•  Exploration  -  What  if  I  do  this? 
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